1. Field of the Invention
The present invention relates to the transmission of data and messages via a network, and more particularly, to a system and method that provides for the flexible and secure transfer of data and the use of a messaging component as a common network connection for access by execution threads to the network, and for determining a manner of transferring data.
2. Description of the Related Art
Most homes presently have at least one television that is connected to a digital cable network that transports signals representing broadcast network and/or cable premium channels as well as other types of programming such as pay-per-view movies or special event programming to one or more televisions within the home.
Some of the signals that are transmitted to the home via the digital cable network, such as premium and pay-per-view signals, are scrambled. In order to view these signals unscrambled, the television is connected to the digital cable network via a box, referred to as a set-top box (STB) that unscrambles the signals. In addition to the STB, the digital cable network also typically includes at least one Cable Head End (CHE) computing system that interacts with the STB.
Since the STB is coupled to the digital cable network and the CHE, it would be beneficial to be able to run application, or program code, on the STB and to allow the application to communicate with an application executing on another computing system such as the CHE via the digital cable network. While the CHE may be a computing system with ample resources for executing application software, the STB has traditionally been limited in its computing resources. Since there are drawbacks (e.g., cost) associated with upgrading the STBs, it would be beneficial for program code that executes on an existing STB to be able to access other computing systems via the digital cable network.
Many currently available STBs, such as those available from Scientific Atlanta, have one or more connectors (e.g., a USB connector) for physically connecting an external device to the STB. Examples of devices that may be connected to the STB include, but are not limited to, printers, image capture devices such as a digital still or video camera, scanner, etc.
In commonly-assigned U.S. patent application Ser. No. 09/723,976, entitled “Digital Image Retrieval and Storage”, which was filed on Nov. 28, 2000 and is incorporated herein by reference in its entirety, a STB executes a driver which interfaces with a device connected to the STB. Briefly, the STB identifies a driver for use with a device currently connected to the STB, the driver executes on the STB for interfacing with the device. In the case of an image capture device, for example, an appropriate driver executing on the STB may be used to retrieve a digital image from the device for upload to a computing system such as a CHE via the STB.
In a case that a printer is connected to the STB, the STB might be used to download print data for printing by the printer via the STB. In such a case, code executing on the STB would receive the print data and forward it to the printer.
An application that executes on the STB may need to retrieve data from the CHE or other server. For example, the STB may execute a “deli” application that displays a menu of foods for take out or delivery. By downloading the menu, the deli application executing on the STB is able to keep the food offerings current.
FIG. 1 illustrates an architecture designed by Scientific Atlanta for use in a digital cable network environment, wherein software that is used to control the digital network, referred to as Digital Network Control System (DNCS) 103, includes a pass-through messaging mechanism for communication between CHE 101 and STB 102.
The pass-through messaging mechanism of DNCS 103, known as DSM-CC Pass-Thru messaging (not shown), passes messages from CHE 101 to STB 102. In order to send a message from CHE 101, a transport service connection is established. A transport service, which is a service that is provided by the transport layer of a network communication protocol stack to higher protocol stack levels (e.g., session and application layers), may be connection-oriented or connectionless.
With a connection-oriented transport service, a connection is established between end points, which remains in existence until it is closed. The Transport Control Protocol (TCP) is an example of a transport layer communication protocol that is connection-oriented. In contrast to a connection-oriented service, in a connectionless service, a dedicated connection that remains open until it is closed does not exist. The User Datagram Protocol (UDP) is an example of a connectionless communication protocol.
Both a connection-oriented and a connectless transport service have associated transport primitives (or operations) to access the service. One such primitive is a socket primitive. The socket primitive is used to create a socket, which is a communication end point, so that process 108 of application 106 running on CHE 101 can send a message to thread 117 of STB 102. Information that is passed to the socket primitive includes quality of service information (e.g., reliability, stream versus byte transmission) as well as a communication protocol (e.g., TCP or UDP).
Both a TCP message and a UDP datagram include an Internet Protocol (IP) header that contains a destination address as well as a source address. Source and destination addresses in an IP header include an IP address and either a TCP or a UDP header identifier that is referred to as a port number. The combination of an IP address and a port number corresponds to a socket.
In addition to being either connection-oriented or connectionless, a socket may be bi-directional. When a socket is configured for TCP, it is connection-oriented, and it provides a reliable end-to-end data stream. In contrast, when the socket is configured for UDP, it is connectionless and there is no assurance of data delivery.
Application 106 running on CHE 101 may include multiple processes and/or subprocesses that communicate with STB 102. For example, process 108 may forward a message to thread 117 executing on STB 102. A message originating from process 108 may be sent, via TCP socket 112A, to DNCS 103. DNCS 103 forwards the message to STB 102 via UDP socket 113. The message is then forwarded to thread 117 via digital cable network 105. QPSK (Quadrature Phase-Shift Keyed) 104 uses a digital frequency modulation technique for sending data over a coaxial cable network. The coaxial cable network comprises a fiber optic cabling connecting hubs 127. Fiber optic cabling is also used to connect hub 127 to one or more nodes 129, which may in turn be connected to one or more STBs 102 using coaxial cabling.
DNCS 103 determines whether the message was sent to STB 102, and notifies the sending process 108 accordingly via Transport Control Protocol (TCP) connection 112A.
Using this architecture, each thread, process and/or application executing on CHE 101 must establish a separate connection to DNCS 103 in order to communicate with a STB application or thread. That is, each process and subprocess, or thread, that uses the pass-through mechanism of DNCS 103 must establish a separate TCP connection.
Thus, for example, separate TCP sockets (e.g., sockets 112A and 112B) are needed for both processes 108 and 109 to communicate with thread 117.
The DNCS listens on a well-known port for a connection request originating from CHE 101. Upon receipt of such a request, another socket is created, in addition to the well-known port's socket, to communicate with the requestor. In addition to the DNCS, other servers, such as a File Transfer Protocol (FTP) server, open a second port in response to a message received via the first, well-known port.
However, the well-known port approach does not aid in reducing the number of sockets used, since each application, process or thread on CHE 101 that uses pass-thru messaging must have its own socket on DNCS 103.
Alternatively, it might be possible to reduce the number of ports and use shared memory to store messages that may be retrieved by a message recipient. One concern with this approach has to do with security, since any application, process or thread which has access to the shared memory has access to the messages and data stored in shared memory. This is especially of concern if the message contains sensitive information such as financial or other information.
The number of needed ports may be reduced by dynamically creating a port such as is done with a well-known port. However, there are security concerns with this approach as well. It is possible that the port creator (e.g., an FTP server), is not trusted, or cannot be verified, and may be impersonated by another that has placed itself in the port creator's position. In so doing, the impersonator can control the messaging and at a very least monitor messages intended for the second port.
In addition to the problems just discussed with the architecture shown in FIG. 1, there is no ability within the architecture to select a method of transport based on considerations associated with CHE 101 and/or STB 102.
Such considerations include whether the data that is to be sent via the network is to be encrypted and/or sent via a secure communications channel. It may be desirable to use bi-directional communication and/or a connection-oriented communications channel.
It would also be beneficial to be able to take into account the current load of CHE 101, or a server that is being used to transfer data. For example, where one server is currently very busy servicing requests, if there is another less busy server that is able to service a request, it would be beneficial to be able to suggest that the request be serviced by the other server. That is, it would be beneficial to be able to perform load balancing across servers used to service requests.
Therefore, it would be beneficial to have an ability to negotiate a manner of communicating via a network so that needs and capabilities of the client STB and a server such as the CHE may be taken into account. Generally, it would be beneficial to have a mechanism for messaging and data transfer, via a network, that is flexible as well as secure.